A successful communication network depends in large part on planning. Part of planning includes designing the various devices in the network for ease of management. Managed devices may include routers, switches, access servers, and the like. To this end, a communication protocol known as Simple Network Management Protocol (SNMP) was developed and is commonly utilized. SNMP operations include “Get” and “Get-next” requests for reading information and “Set” requests for configuring information. Typically, most SNMP requests are requests to “Get” data. Exemplary SNMP operations are described in Table 1, listed below.
TABLE 1OperationDescriptionGet-requestRetrieve a value from a specific MIB variable.Get-next-requestRetrieve a value of the object instance that is next inthe lexicographical order of a specific MIB variablespecified. With this operation, a SNMP manager doesnot need to know the exact variable name. Asequential search is performed to find the neededvariable within a table.Get-responseThe reply to a get-request, get-next-request, andset-request sent by a NMS.Set-requestStore a value in a specific variable.TrapAn unsolicited message sent by a SNMP agent to aSNMP manager indicating that some event hasoccurred.
FIG. 1 is a block diagram that illustrates a typical network employing SNMP to manage network devices. In general, the management of the network is controlled by a Network Management System (NMS) 100. A NMS 100 executes management applications 120 that monitor and control managed devices 105 at regular intervals via a SNMP Manager 125. The SNMP Manager 125 forms Protocol Data Units (PDUs) and sends them to the managed devices. Each managed device 105 includes a SNMP agent 110 that processes the PDU, authenticates it and retrieves information requested by the NMS 100. Each managed device 105 maintains this requested in formation in a Management Information Base (MIB) 115. Some MIB 115 variables may depend on other variables. The values for the variables are typically stored in a table. There may be many tables in a particular MIB 115 and there may be more than one MIB 115 for each managed device. The size of a MIB table may vary from a few values to hundreds or even thousands of values depending on the managed device 105.
FIGS. 2A-2C illustrate typical timing of SNMP requests and responses. FIG. 2A is a timing diagram that illustrates typical timing of SNMP requests issued by a NMS. Reference numeral 214 indicates the time during which SNMP requests are generated, also known as the “burst”. As shown in FIG. 2A, SNMP requests 200-208 are typically periodic. The same set of requests is typically repeated after interval T (210). Moreover, the sequence and content of SNMP requests to a particular SNMP agent are typically invariant over multiple bursts. Thus, a SNMP agent typically responds to the same set of SNMP requests each period.
FIG. 2B is a timing diagram that illustrates typical SNMP agent CPU loading due to SNMP requests. The agent SNMP CPU loading is typically irregular, with a spike 220 in CPU loading occurring at the beginning of each burst 222. This spike 220 in CPU loading is typically due to the initialization of data structures at the beginning of each burst.
FIG. 2C is a timing diagram that illustrates typical SNMP requests and corresponding responses. Requests 230-236 correspond with responses 238-244, respectively. Note there is a relatively small time between each successive request and a relatively long period between each corresponding response. This added delay is typically caused by the time required for the SNMP agent to process the preceding request. Thus, response 240 is delayed by the processing time for request 230. The effect of processing delays is also cumulative. Hence, response 242 is delayed by the processing time for requests 230 and 232 and response 244 is delayed by the processing time for requests 230, 232 and 234. This behavior means that the number of requests a NMS can send per burst is limited by the size of period T 246.
SNMP agent processing often requires collecting the requested information from one or more subsystems. For example, a router may support multiple interfaces and the SNMP agent must collect information from each of the interfaces. Interfacing with another subsystem typically involves communicating with an application or process running on the same CPU or on a different CPU. This inter-process communication (IPC) typically results in communication delays that increase the amount of time required to collect information. The inter-process communication also uses precious CPU cycles that could otherwise be utilized for the core functionality of the network device. For example, inter-process communication delays for a network router SNMP agent use CPU cycles that could otherwise be utilized for core routing functions.
Moreover, each request is handled serially, without regard to preceding or succeeding requests. If data request from one subsystem is interspersed with data requests for another subsystem, then this process is inefficient. For example, a burst that includes a request for variable X from subsystem 1 (X1), followed by a request for Y2 followed by a request for Z1 generates two requests from subsystem 1 and one from subsystem 2.
There is an increasing trend towards putting more subsystems in network devices, resulting in more SNMP requests and more inter-process communication. But as discussed above, the number of requests a NMS can send per burst is limited by the size of period T 246. In addition, management applications typically require current information regarding managed devices. Thus, it is desirable to increase the amount of data collected without decreasing the frequency of data collection (increasing the period T 246).
What is needed is a solution that enables responding to network management requests relatively efficiently thereby increasing the amount of data that may be requested per unit time. A further need exists for such a solution that enables relatively even processing loads when responding to a group of requests. A further need exists for such a solution that can be implemented without network manager modification. Yet another need exists for such a solution that uses open and well-understood standards.